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Remarks 

Claims 1-21 are currently pending in the subject application and are presently under 
consideration. 

Favorable reconsideration of the subject patent application is respectfully requested in 
view of the comments herein. 

I. Rejection of Claims 1-9 and 16-20 Under 35 U.S.C. §103(a) 

Claims 1-9 and 16-20 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Chen, et al. (US 5,812,780) in view of Bernardin, et al. (US 2003/0191795). It is requested that 
this rejection be withdrawn for at least the following reasons. Chen, et al. and Bernardin, et al, 
when taken alone or in combination, fail to teach or suggest all elements recited in the subject 
claims. 

[T]he prior art reference (or references when combined) must teach or 
suggest all claim limitations. See MPEP §706.02(j). See In re Vaeck, 947 
F.2d 488, 20 USPQ2d 1438 (Fed. Cir. 1991). 

The subject matter claimed herein relates to loading a test server with simulated user 
interaction to determine one or more metrics regarding performance of the server. According to 
one example, different user profiles or characteristics can be utilized in the same tests to better 
simulate actual user use. To this end, claim 1 recites dynamically adjusting at least one 
characteristic of at least one of the simulated users based at least in part on a browser type 
related to the simulated user, for distribution thereof as a percentage of total requests sent to a 
server being load tested. Independent claim 16 recites similar aspects, namely dynamically 
adjusting the user characteristics based on one or more browser types during the testing of the 
server. Chen, et al. and Bernardin, et al, when taken alone or in combination, fail to teach or 
suggest this aspect. 

Chen et al. relates to a system for the provision of realistic load conditions on a server 
application by simulating the behavior of multiple users operating client software. As the 
Examiner clearly acknowledges, however, Chen et al. does not disclose dynamically adjusting at 
least one characteristic of at least one of the simulated users based at least in part on a browser 
type related to the simulated user, or any behavior regarding a browser type as recited in the 
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subject claims. (See Final Office Action dated February 25, 2008). The Examiner offers 
Bernardin, et al. to cure this deficiency; however, Bernardin, et al. is similarly lacking. 

Bernardin, et al. relates to a system for scheduling tasks in a parallel architecture wherein 
an application program interface can be provided to facilitate remote operation with the 
architecture. The task scheduling can be automated based on priority of jobs, for example, and 
task results can be sent to the requestor of the task. Additionally, Bernardin, et al. describes an 
API for the system that allows for creating an interface that can be utilized by a web browser. 
However, Bernardin, et al. fails to disclose or suggest determining characteristics or any 
characteristics comprising a browser type of a simulated user, much less dynamically adjusting 
such characteristics as recited in the subject claims. 

In fact, Bernardin, et al. is completely silent regarding such aspects. In the sections cited 
by the Examiner in support, Bernardin, et al. discloses functionality of a Broker, which receives 
task requests and handles scheduling thereof; namely, the section discloses determining "at least 
one, two, three, four, or more of the following attributes of the available processing resource: (i) 
operating system of the processing resource; (ii) available memory of the processing resource; 
(iii) available disk space of the processing resource; (iv) security features of the processing 
resource; (v) speed of the processing resource; (vi) availability of locally-cached data at the 
processing resource; (vii) typical frequency of local user activity at the processing resource; and 
(viii) time of most recent local user activity at the processing resource." {See paragraph [0075]). 

Additionally, other sections cited by the Examiner discuss resolving scheduling 
problems, caching, data set utilization, interactive modeling/data visualization, and an 
administrative interface accessible by compatible browser. (See paragraphs [0287], [0326], 
[0352], and [0361]). Nowhere does Bernardin, et al. contemplate adjusting simulated user 
characteristics based on a browser type or characteristics comprising a browser type of a 
simulated user as recited in the subject claims. As far as allowing accessibility to an API from 
different compatible browsers as disclosed by Bernardin, et al, this is not indicative of 
performing any action (such as dynamically adjusting characteristics) or differentiating based on 
a type of browser as recited in the subject claims, much less even taking such into consideration. 
For example, before an action can be performed based on a browser type, the browser type must 
be acquired; both references are silent in regard to this aspect. Thus, Bernardin, et al. does not 
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differentiate between browser types and cannot be said to teach aspects regarding determination 
of a browser type. 

Furthermore, claim 5 recites the characteristic statistically determined based on web log 
records. Though Chen, et al. discloses utilizing a log file, the log file is used to report statistics 
of the load testing services. Conversely, claim 5 recites characteristics statistically determined 
from the log, meaning that not only is the log used post-creation, but it is utilized to determine 
characteristics based on the contents. For example, simulated users can be based in part on users 
discerned from the log file. Chen, et al. discloses creating the log file. Thus, the references fail 
to teach or suggest this additional aspect. 

Moreover, the Examiner asserts that combining Chen, et al. and Bernardin, et al. would 
"allow an administrator to monitor and manage the server with increasing secured network, and 
increased convenience to authorized users from any compatible browser." (See Final Office 
Action dated February 25, 2008). Assuming arguendo that the combination teaches such 
aspects, this is not what the applicants arc claiming. The claims recite dynamically adjusting 
simulated user characteristics based on a browser type of a simulated user, not an administrator 
monitoring and managing a server via a compatible browser. In applicants' claims, the browser 
type is causing the dynamic adjustment of user characteristics; in Bernardin, et al, however (and 
the combination with Chen, et al), the browser type is not even considered. 

In addition, as Bernardin, et al. teaches an API for managing a system, combining Chen, 
et al. and Bernardin, et al. would merely produce a web-accessible API for a load server testing 
application. This combination does not teach or suggest adjusting user characteristics, or 
anything, based on a browser type as recited in the subject claims. 

In view of at least the foregoing, it is readily apparent that Chen, et al. and Bernardin, et 
al, when taken alone or in combination, fail to teach or suggest all aspects of claims 1 and 16. 
Therefore, rejection of these claims, as well as, claims 2-9 and 17-20, which respectively depend 
therefrom, should be withdrawn. 

II. Rejection of Claims 10-15 and 21 Under 35 U.S.C. §103(a) 

Claims 10-15 and 21 stand rejected under 35 U.S.C. § 103(a) as being anticipated by 
Malmskog, et al. (US 6,721,686) in view of Bernardin et al. It is requested that this rejection be 
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withdrawn for at least the following reasons. Malmskog, et al. and Bernardin, et al, when taken 
alone or in combination, fail to teach or suggest all elements recited in the subject claims. 

As described, the subject matter claimed herein relates to loading a test server with 
simulated user interaction to determine one or more metrics regarding performance of the server. 
According to one example, different user profiles or characteristics, such as browser type, can be 
utilized in the same tests to better simulate real world user use. To this end, claim 10 recites a 
plurality of simulated users dynamically adjusted based on predetermined weightings of a user 
profile related to at least one of the simulated users having weighted characteristics that 
comprises at least a browser type therein. Claim 21 recites similar aspects, namely means for 
dynamically adjusting characteristics of a simulated user while loading the server. Malmskog, 
et al. and Bernardin, et al., when taken alone or in combination, fail to teach or suggest this 
aspect. 

Malmskog, et al. relates to a system for generating a load on a web server and testing the 
performance thereof. Specifically, a number of synthetic clients can be produced utilizing 
various communication metrics, bandwidth, packet loss rate, delay, etc. As the Examiner clearly 
acknowledges, however, Malmskog et al. does not disclose weighted characteristics comprising 
at least a browser type as recited in the subject claims. {See Final Office Action dated February 
25, 2008). The Examiner offers Bernardin, et al. to cure this deficiency; however, Bernardin, et 
al. is similarly lacking as described previously. 

In particular, Bernardin, et al. does not contemplate simulated user characteristics 
comprising a browser type or utilizing such as recited in the subject claims. As far as allowing 
accessibility from a compatible browser, as recited in the sections cited by the Examiner, this is 
not indicative a browser type characteristic of a simulated user that can be used to adjust the 
simulated user as claimed. Though Bernardin, et al. may be operable with multiple compatible 
browsers, this does not indicate that a browser type is utilized as a characteristic in any way {e.g., 
that the browser type is determined and used as a simulated user characteristic, much less a 
weighted one) as in the subject claims. 

Furthermore, combining Malmskog, et al. and Bernardin, et al. , if the references are even 
combinable, produces a web accessible API for the test load system of Malmskog, et al. 
However, the browser type utilized to access the API has no relevance to the system other than 
compatibility from the accessing user's standpoint. 
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In view of at least the foregoing, it is readily apparent that Malmskog, et al and 
Bernardin, et al, when taken alone or in combination, fail to teach or suggest all aspects of 
claims 10 and 21. Therefore, rejection of these claims, as well as, claims 11-15, which depend 
therefrom, should be withdrawn. 

Conclusion 

The present application is believed to be in condition for allowance in view of the above 
comments. A prompt action to such end is earnestly solicited. 

In the event any fees are due in connection with this document, the Commissioner is 
authorized to charge those fees to Deposit Account No. 50-1063 [MSFTP637US]. 

Should the Examiner believe a telephone interview would be helpful to expedite 
favorable prosecution, the Examiner is invited to contact applicants' undersigned representative 
at the telephone number below. 

Respectfully submitted, 
Amin, Turocy & Calvin, llp 

/Himanshu S. Amin/ 

Himanshu S. Amin 
Reg. No. 40,894 



Amin, Turocy & Calvin, llp 
24 th Floor, National City Center 
1900 E. 9 th Street 
Cleveland, Ohio 44114 
Telephone (216) 696-8730 
Facsimile (216) 696-8731 
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